Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0134/info_91/508.txt

Text File | 1997-04-16 | 34KB | 783 lines

Info-Atari16 Digest         Fri, 27 Sep 91       Volume 91 : Issue 508

Today's Topics:
                           CPX Information
            Empire - where to get? (Interstel adr. wanted)
                             Hebrew Fonts
                  lharc 2.01e vs zoo 2.1: some tests
               ST Magazines (was More Lies From Atari?)
             ST Magazines (was Re: More Lies From Atari?)
                 TeX, which do I get? (Now that I kno
                      Trip-A-Tron (Colourspace)

Welcome to the Info-Atari16 Digest.  The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out.  Please send notifications about broken digests or bogus messages
to [e-mail].

Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
instead of the moderators are likely to be lost or ignored.

If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------

Date: 26 Sep 91 06:31:17 GMT
From: mcsun!news.funet.fi!funic!nic.funet.fi![e-mail] (Kimmo
 Lahtinen)
Subject: CPX Information
To: [e-mail]

In ST-Computer Magazine there has been several articles about
CPX, but of course in German.
--
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Kimmo Lahtinen                      E-Mail : [e-mail] or
Finnish Meteorological Institute             [e-mail]
''                                    Phone  : [phone]
Possessed by a Spirit               G3 Fax : [phone]

------------------------------

Date: Fri, 27 Sep 91 14:08:24 MEZ
From: Wolfgang Ley <[e-mail]>
Subject: Empire - where to get? (Interstel adr. wanted)
To: Atari ST users forum <[e-mail]>

Hi ppl,

I would like to have the Atari-ST Version of Empire (Wargame of the
century - NOT "The empire strikes back").
I can't find a distributor of this game... all i know is that the
programm is from INTERSTEL. Is there anyone out who knows the adress
of Interstel?? Is there an other way to get Empire??

Thanks, Wolfgang.

---------------------------------------------------------------------------
     Wolfgang Ley                e-mail:
     Teichstrasse 9              from BITNET  : [e-mail]
3392 Clausthal-Zellerfeld        from Internet: [e-mail]
     Tel. [phone] (voice)               or  [e-mail]
---------------------------------------------------------------------------

------------------------------

Date: 26 Sep 91 15:10:07 GMT
From:
 europa.asd.contel.com!darwin.sura.net!haven.umd.edu!uflorida!travis!jgj@uunet.u
 u.net (Jeff Jackson)
Subject: Hebrew Fonts
To: [e-mail]

I wish to thank the numerous people who responded to my posting looking for
a Hebrew Font.  I found two sets of freely available ones:

> Date:         Thu, 05 Sep 91 13:52:16 IST
> From: [e-mail]
> Organization: Ben-Gurion University, Beer-Sheva, Israel
> Subject:      Re: Hebrew Font Wanted
> To: [e-mail]
>
> Hello. You can put Mac hebrew fonts from my FTP anonymous 132.72.20.2
> HEBFONT.HQX fonts
> HEBSYS.HQX Hebrew system 6.03
> RAVKTAV.HQX Hebrew editor
>              Michael

and

> Date: Thu, 5 Sep 91 19:35:42 -0400
> From: [e-mail] (Jonathan Brecher)
> To: [e-mail] (Jeff Jackson)
> In-Reply-To: [e-mail]'s message of 4 Sep 91 20:04:06 GMT
> Subject: Hebrew Font Wanted
>
> >Is there anywhere I can get a postscript Hebrew Font?  PD would be nice
> >but $$$ are not out of the question.  Thankx in advance
>
> Oh boy, time to toot my own horn!
> You can get my ShareWare Hebrew fonts from mac.archive.umich.edu in
> /mac/system.extensions/fonts/type.one.fonts.
>
> Look for the files ShalomOldStyle.hqx, ShalomStick.hqx and ShalomScript.hqx
> (or something similar). If you have any problems, drop me a line and I'll
> upload you some fresh copies.
>                                       jonathan brecher


The first one didn't quite fit my needs because I needed full
pointing.  The second I found after being better than half way through
designing my own.  It has full pointing, though it does it with zero
sized characters with negative offsets (I think).  My screen display
software doesn't something about it.  I decided I would only be
satisfied if I did my own, so I am completing it.

Those of you who wanted one too, can get one of the above, or wait
till I am finished with mine and I'll email it to you.  It will
consist of 12, 18, 24 and 36 pt screen fonts (For Monochrome Atari ST
PageStream), the FM (font metrics) and DMF (dot-matrix font) files as
well as a Type-3 postscript file and the PSF file for interfacing it
to PageStream.  My big goal is for it to look good at 12pt on a puny
300dpi printer.  I suspect the other two would look much better at
1200dpi.

The way I am handling the overstriking is kerning pairs.  There are
two character widths for the consonants.  All the vowel points (except
holem, which is special because it goes in the corner instead of the
center), are the same size as the small consanants.  "We" would be a
waw with a seghol under it.  For the large consonants, a pad character
must be added after the vowel to make up for its smaller size, hence
"Be=".  For holem, there is both a small (o) and a large (O) one.  It
must be put after the character to its left (BOY) would put a Holem
between Beth and Yodh.  Holem-waw is "w".

I have the basic set done, but I am still not happy with Aleph and a
couple others, plus I still discover an occassional bug in my kerning
(lots of pairs).

--
============================================================================
Jeffrey Glen Jackson  _|_Satan jeered, "You're dead meat Jesus, I'm gonna
[e-mail] |     bust you up tonight."
x5120                  | Jesus said, "Go ahead, make my day."


------------------------------

Date: 26 Sep 91 06:45:25 GMT
From: convex![e-mail] (William Rosenkranz)
Subject: lharc 2.01e vs zoo 2.1: some tests
To: [e-mail]

friends-

to help understand the claim that lharc is the best thing since sliced
bread, and so much better than zoo 2.1, i ran some tests. this is a rather
long post. if you think i am crazy, hit 'n' now. or put me in your kill
file :-). if you have an open mind, read on for enlightenment...

summary:                zoo 2.1 is just about as fast as lharc 2.01e and
                        makes files about the same size.

rumors dispelled:       using assembly language offers huge speed advantages
                        over C in the problem domain of file archivers.

rumors confirmed:       C programs compiled with GNU C offer significant
                        advantages (read on...). C programs compiled with
                        GNU C tend to be rather large executables.

tests:                  1       archive of archives
                        2       archive of programs and their docs
                        3       test wildcard expansion and long command lines
                        4       handle ~C interrupt

i felt these sorts of tests were important to me. they may or may not be
your cup of tea. in that case do your own tests (and report them to the
rest of us). missing is a test of predominantly text files. also missing
are tests of directory trees and very large files. i've spent far too much
time on this already, just to prove a point.

test platform is mega4 (4 MB) 8 Mhz, TOS 1.2, using gulam CLI. environment
included TMP=ramdisk and TEMP=ramdisk (i confirmed there was no use of
hard disk by observing that no disk access lights went on).

all tests were done with files (executable, data files, and archives) in
a 1.5MB ramdisk. this tends to eliminate the effect of partitions which
are not empty, differences in drive seek rates, etc. knowing that zoo is
sensitive to i/o, i wanted to factor out i/o from the test as much as i
could. i did not want to clear an entire partition for this.

versions of each program were as follows:

        lharc 2.01e (questor, Assemblerversion vom 14.07.1991)
        zoo 2.1 (1991/07/14 22:39:26)

i would call this "equal" technology since the versions were realized
on the same dates! zoo was compiled with GNU c (gcc) though i do not know
which version. i confirmed this by both "printstk zoo.ttp" which did not
fail, listing a reasonable stacksize (16k) and by "strings -10 zoo.ttp"
which listed ascii strings that would appear if gcc was the compiler.
it also looks like zoo 2.1 was compiled with MiNT so that it could be
"backgrounded" in a multiprocessing environment. i could be way off base
here, however. i just spotted the string "MiNT" in the .ttp. i saw no
evidence that lharc was equally endowed. it also looks like zoo may support
UNIXMODE tho i don't use it myself. UNIXMODE allows configuration so that
forward slashes "/" can be used in file paths as well as backslash "\".
lharc does not appear to support this either. note that if needed, the
zoo program's stack could be increased with the fixstk utility offered
with GNU C. i do not know how lharc does its memory management nor whether
it would ever need stacksize adjustments. my guess is that memory is
either statically allocated with fixed size arrays or with GEMDOS Malloc.
i would know for sure if source was available. i am unable to ascertain
how much memory lharc Mallocs if it does do so. this can be important
in a multiprocessing environment like MiNT. if it Mallocs all memory,
then no other program could be started until lharc finishes.

commands used:

        add files:      lharc a lll <files>     zoo ah zzz <files>
        extract files:  lharc x lll             zoo -extract zzz
        list archive:   lharc v lll             zoo -list zzz

gulam's time command was used to get the times which are all in seconds
unless otherwise noted.

----------------------------------------------------------------------------
test 1:

used these files for data (chosen at random):

-rw------- 1 u            39071 Sep 22 21:10 f1.zoo
-rw------- 1 u            69918 Jul 23 00:46 f2.zoo
-rw------- 1 u             2303 Sep  4 03:16 f3.h
-rw------- 1 u            74183 Sep 22 21:15 f4.zoo

lharc: add files:

this took 82 seconds to complete, resulting in a file of size 181588 bytes.

lharc: extract files:

this took 27 seconds. HOWEVER, the dates and times of the extracted files
were NOT correct. they were the current date and time NOT the times in
the archive:

-rw------- 1 u            39071 Sep 25 21:56 f1.zoo
-rw------- 1 u            69918 Sep 25 21:56 f2.zoo
-rw------- 1 u             2303 Sep 25 21:56 f3.h
-rw------- 1 u            74183 Sep 25 21:56 f4.zoo

lharc: list files:

LHarc 2.01e (c)Yoshi, Quester, 1988-90.(Assemblerversion vom 14.07.1991)


Listing of archive : 'LLL.LZH'

  Name          Original    Packed  Ratio     Date   Time   Attr Type  CRC
--------------  --------  -------- ------ -------- -------- ---- ----- ----
F1.ZOO
                   39071     37952  97.1% 91-09-22 21:10:22 ---w -lh5- 3386
F2.ZOO
                   69918     68195  97.5% 91-07-23  0:46:32 ---w -lh5- E91B
F3.H
                    2303      1127  48.9% 91-09-04  3:16:56 ---w -lh5- 0526
F4.ZOO
                   74183     74183 100.0% 91-09-22 21:15:04 ---w -lh0- FA5E
--------------  --------  -------- ------ -------- --------
     4 files      185475    181457  97.8% 91-09-25 21:15:48





zoo21: add files:

this took 93 seconds to complete, resulting in a file of size 181865 bytes.


zoo21: extract files:

this took 25 seconds. the times and dates of extracted files were exactly
correct (same dates and times as files in the archive).


zoo21: list files

Archive zzz.zoo:
Length    CF  Size Now  Date      Time
--------  --- --------  --------- --------
   39071   3%    37954  22 Sep 91 21:10:22+64 3386   f1.zoo
   69918   3%    68197  23 Jul 91 00:46:32+64 e91b   f2.zoo
    2303  51%     1129   4 Sep 91 03:16:56+64 0526   f3.h
   74183   0%    74183  22 Sep 91 21:15:04+64 fa5e   f4.zoo
--------  --- --------  --------- --------
  185475   2%   181463     4 files





----------------------------------------------------------------------------
test 2:

used these files (from mint 0.8 distribution, this was in file f4.zoo in the
test above, by the way, a "zoo ah" archive):

-rw------- 1 u            25636 Apr 17 23:40 bgacc.acc
-rw------- 1 u             2168 Apr 18 00:29 bgacc.doc
-rw------- 1 u             1189 Dec  9 23:05 gem.prg*
-rw------- 1 u             9871 Mar 16 18:12 init.doc
-rw------- 1 u            23586 Apr  5 23:18 init.prg*
-rw------- 1 u              651 Dec 15 00:15 init.rc
-rw------- 1 u            74125 Apr 18 00:19 mint.prg*



lharc: add files:

this took 63 seconds to complete, resulting in a file of size 73820 bytes.


lharc: extract files:

this took 23 seconds. again, dates were wrong:

-rw------- 1 u            25636 Sep 25 22:02 bgacc.acc
-rw------- 1 u             2168 Sep 25 22:02 bgacc.doc
-rw------- 1 u             1189 Sep 25 22:02 gem.prg*
-rw------- 1 u             9871 Sep 25 22:02 init.doc
-rw------- 1 u            23586 Sep 25 22:02 init.prg*
-rw------- 1 u              651 Sep 25 22:02 init.rc
-rw------- 1 u            73820 Sep 25 22:01 lll.lzh
-rw------- 1 u            74125 Sep 25 22:02 mint.prg*

lharc: list files:

LHarc 2.01e (c)Yoshi, Quester, 1988-90.(Assemblerversion vom 14.07.1991)


Listing of archive : 'LLL.LZH'

  Name          Original    Packed  Ratio     Date   Time   Attr Type  CRC
--------------  --------  -------- ------ -------- -------- ---- ----- ----
BGACC.ACC
                   25636     13854  54.0% 91-04-20 15:40:26 ---w -lh5- EAF8
BGACC.DOC
                    2168      1065  49.1% 91-04-20 16:29:00 ---w -lh5- BD8E
GEM.PRG
                    1189       866  72.8% 90-12-12 14:05:20 ---w -lh5- C714
INIT.DOC
                    9871      3961  40.1% 91-03-19  9:12:10 ---w -lh5- D569
INIT.PRG
                   23586     13558  57.5% 91-04-08 14:18:34 ---w -lh5- B325
INIT.RC
                     651       353  54.2% 90-12-17 15:15:46 ---w -lh5- 21B5
MINT.PRG
                   74125     39917  53.9% 91-04-20 16:19:22 ---w -lh5- 496E
--------------  --------  -------- ------ -------- --------
     7 files      137226     73574  53.6% 91-09-25 22:23:24






zoo21: add files:

this took 74 seconds to complete, resulting in a file of size 74183 bytes.


zoo21: extract files:

this took 23 seconds. dates ok.

-rw------- 1 u            25636 Apr 20 15:40 bgacc.acc
-rw------- 1 u             2168 Apr 20 16:29 bgacc.doc
-rw------- 1 u             1189 Dec 12 14:05 gem.prg*
-rw------- 1 u             9871 Mar 19 09:12 init.doc
-rw------- 1 u            23586 Apr  8 14:18 init.prg*
-rw------- 1 u              651 Dec 17 15:15 init.rc
-rw------- 1 u            74125 Apr 20 16:19 mint.prg*
-rw------- 1 u            74183 Apr 18 00:29 zzz.zoo


zoo21: list files:

Archive zzz.zoo:
Length    CF  Size Now  Date      Time
--------  --- --------  --------- --------
   25636  46%    13856  17 Apr 91 23:40:26+64 eaf8   bgacc.acc
    2168  51%     1067  18 Apr 91 00:29:00+64 bd8e   bgacc.doc
    1189  27%      868   9 Dec 90 23:05:20+64 c714   gem.prg
    9871  60%     3963  16 Mar 91 18:12:10+64 d569   init.doc
   23586  43%    13560   5 Apr 91 22:18:34+64 b325   init.prg
     651  45%      355  15 Dec 90 00:15:46+64 21b5   init.rc
   74125  47%    39919  18 Apr 91 00:19:22+64 496e   mint.prg
--------  --- --------  --------- --------
  137226  47%    73588     7 files




----------------------------------------------------------------------------
test 3:

i made a dummy directory with enough files so that the command line length
would be longer than 125 chars (which is what Pexec normally can handle).
GNU C programs can exploit ARGV extended argument passing (which is sanctioned
by atari). gulam can handle this as well with "setenv env_style mw" which
i set.

files were:

xxxxxxxx.001  xxxxxxxx.004xxxxxxxx.007  xxxxxxxx.010  xxxxxxxx.013
xxxxxxxx.002  xxxxxxxx.005xxxxxxxx.008  xxxxxxxx.011  xxxxxxxx.014
xxxxxxxx.003  xxxxxxxx.006xxxxxxxx.009  xxxxxxxx.012  xxxxxxxx.015

with zoo i did:

        zoo a zzz *

and

        zoo a zzz '*'

both worked. that means zoo can handle long lists of file names and
wildcards itself.

i tried:

        lharc a lll *

and my system crashed! lharc does NOT handle extended args. and what's more
it crashed my system! i did not want to reboot again so i did not test to
see if it handles wildcards itself. this is TOTALLY unacceptable.


----------------------------------------------------------------------------
test 4:

i tested each program's ability to be interrupted. during archive creation,
i issued a control-C to both. both stopped. however, lharc left a file
behind "lharc.)2(" so it does not really handle signals. zoo does since
it was compiled with GNU C library (another reason why it is better to
use a compiler with a decent library). zoo cleaned up after itself.


----------------------------------------------------------------------------
recap:

                create archive  extract files   comments
                time    size    time

test 1  lharc   82      181588  27              extracted file dates wrong
        zoo     93      181865  25

zoo/lharc ratio 1.13    1.0015  0.926

test 2  lharc   63      73820   23              extracted file dates wrong
        zoo     74      74183   23

zoo/lharc ratio 1.17    1.0049  1.000


conclusions:

tho hardly an exhaustive test, nevertheless i suspect most tests will show
similar results. i am also sure that someone can find an anomoly where either
one kicks the pants of the other.

i draw these conclusions:

        - lharc is no more "blindingly fast" than zoo 2.1. in fact for
          extraction it can be SLOWER. extraction is probably used more
          often by casual users. assembly language lharc is no more than 15%
          faster on average on compression and at best the same or slower
          on extraction as the "hands off" C of zoo. in fact given this
          problem domain (construct a system to compress and store files)
          it appears that C is an excellent choice over assembler. if
          lharc was 2 or 3 times faster i would alter this view. but 15% or
          less is just not enough to warrant the added inflexibility of
          assembler.

        - lharc is not especially better at compressing files. i would
          hardly call less than 0.5% difference significant. in fact since
          you don't store bytes on disk, rather clusters, there may be
          no savings at all on average.

        - zoo archives appear to be larger because of the headers are
          most likely larger for each file. if you examine the sizes of
          the compressed files, you will note that lharc is 2 bytes smaller
          than zoo, appearently independent of file size when lh5
          compression is used.

        - the size of the executables is significantly different. about 2x
          (lharc being the smaller). however, after packing with pfxpak,
          zoo is about 53k and lharc is about 28k. the difference is not
          that significant in a 16 MB partition. what i do find fascinating
          is that the executable for lharc is itself an archive! this is
          a really super hack. incidently pfxpak was written by the very
          same thomas questor who provides the lharc under scrutiny. (and
          thomas, i DID disassemble it, tho the crash in test 3 wiped it
          out since i had the source on the ramdisk. maybe you could mail
          me the source now...:-). still, i generally dislike self extracting
          archives though this is a twist on that concept.

        - lharc's not getting the dates and times of extracted files correct
          is unacceptable. PERIOD. if it can't get this correct, it is
          of no use to me. i need the timestamps preserved because i use
          tools which depend on the relative difference in timestamps
          between files (e.g. make and RCS). if this is a case of RTFM,
          then i will first say "yes, but..." and mention that getting the
          timestamp right should be the default behavior.

        - lharc cannot handle long lists of files. and when you do give it
          such a list, it crashes the system. this is also nasty, unacceptable
          behavior. in contrast, zoo can handle extended args and wildcards
          with ease.

        - the version of zoo sources i have can easily be ported to any
          system with POSIX library and an ANSI C compiler. this includes
          scores of systems from the PC and ST to supercomputers. lharc
          cannot (even if i did have the source) since it is written in
          assembler. note that all assemblers are different on the ST as
          well so that it might take significant effort to compile it
          with another assembler, even on the ST.

        - tho cute and even helpful, the lharc "thermometer" that tracks
          progress with *'s messes up redirected output:

                lharc a lll file >log

          it should be disabled if !isatty(1). zoo has no problem at all
          with stdout redirection to files.

        - nitpicking: zoo lists files one per line. it is easier to grep
          things out for more specialized uses (like making lists of all
          .c files with their statistics).

        - there is one version of zoo 2.1 (that i know of) for ST, unix,
          and PC. i stopped counting the versions of lharc for the ST
          alone at about 6 or 8. there is only one author of zoo.

        - zoo 2.1 can extract files from ANY zoo archive of equal or
          lesser version. older versions of zoo can list any zoo archive
          even if made with a newer version. if a newer version is needed
          to extract files, the older zoo tells you what version you need.
          zoo 2.1 will also (by default) make archives which older versions
          of zoo will extract. you have to ask for the high compression
          algorithm specifically with the "h" command modifier.

        - i can take the zoo 2.1 archive up to a unix (or VMS) system and
          extract the archive with no effort. i do not have to track down
          a version which will extract it. the original version posted to
          the net (source code) works fine. i have tried unlzhing an lh5
          archive on unix with LHarc for unix v1.02 with no luck. it complains
          that it cannot extract this method. in this case someone is going to
          berate me saying "well, you should get this_and_such version and
          quit moaning". i would (naturally) respond with "so how often do
          i have to update lharc on unix to remain current? i already have
          2 versions. how many more do i need? i only need one version of
          zoo 2.1!". if it is any consolation, at least 1.02 does not core
          dump when it finds this out (0.03 does, at least my port on a
          convex does).


        - neither program has a particularly consistent set of commandline
          switches. after years of use, however, i am at least used to zoo.
          and neither program as-is offers any particular advantage over
          the other from the desktop from what i can see. i never use the
          desktop so don't take my word for this. zoo does expand wildcards
          in file lists. i did not test lharc, fearing another system
          crash.

        - comp.binaries.ibm.pc has used and continues to use zoo as its
          primary archiver for posted programs. it also uses zip and
          the occasional lharc file as well, however. now that zoo 2.1
          is out, i see the use of lharc waning there. zip is still used.

i would compliment thomas on a fairly good program, at least a good
improvement over early lharcs on the ST. he has done significant work
to try and eliminate the inconsistencies between lharc versions. however,
i just don't see a huge advantage in using lharc now that zoo 2.1 is
available. and not getting the timestamp correct on extraction is very
bad indeed. is there a bug fix for this or am i missing somthing here?
and not handling long lists of files and crashing when presented with
such a list is beyond unacceptable. note that if he had used C instead
of assembler, especially GNU c, some of these problems would have been
taken care of by the library. as it stands, he has to do this himself.
consider this "user feedback" when you plan the next upgrade, thomas.

i confess that i did not read the docs for lharc. as far as i know the
questor version docs have always been in german up until 2.01e which i
just got within the past 2 weeks. but then again i did not read the docs
for zoo 2.1 either. the only change in zoo 2.1 has been the "h" modifier
for high compression and the "a//" addition for recursive directory searches
so there was no need to read anything. both of these new features were
mentioned in the README file. the rest functions as it always did. nothing
new to learn. i already knew how to use zoo since i have used it for at
least 2+ years.

i claim no authority in the use of lharc. i just ran it as i would zoo or
arc or lharc on unix (the version i have, at least) like the dumb user i
am. if these results can be bettered, please let me know how.

also, i know of some optimizations for zoo which may not have been applied
in the version i have (posted to comp.binaries.atari.st by steve grimm).
i know the unix version with larger i/o buffers is significantly faster
(at least 20% on a convex C210 with VME disks). if that is also true on
the ST, then the small speed advantage lharc has (only on compression, that
is) over zoo goes away. and zoo 2.1 may be even faster than lharc on
extraction in that case.

i note that the speed difference in both test cases is 11 seconds during
archive creation. it might be possible that this is a constant. if so, then
doubling the amount of work will lower the net speed advantage to under 10%.

also note that this version of zoo appeared within days of being posted
to alt.sources. i am sure it has not been tuned in the slightest. and i
hope it stays that way, so we don't end up with 50 versions of zoo.

it would also be nice to look at each program's i/o efficiency by controlled
tests in cluttered hard disk partitions or on virgin-formatted floppies.
i have not done that nor do i think it is worth the effort at this point.
also each program's handling of directory trees should be tested. zoo 2.1
(on the ST only!) now has an improved method for doing recursive hierarchies
(a//). the unix version still uses the "find . -print | zoo aI archive"
method as far as i know. this is not possible with the ST without CLIs that
support pipes. gulam (and the desktop) do not support pipes.

believe it or not i have tried to be impartial. and the benchmarking process
is not alien to me, tho i would not consider this a very thorough test. that
would require a better set of "calibrated" test files (these do exist). i
did not look at a set of files that were predominantly text, eventhough this
is one of my heaviest uses (source archives). however, the files i chose were
probably more indicative of the casual user's needs (programs with docs, and
other archives).

i try to look past speed and size alone. these are not highest on my
priority list for archivers, though they are important. i remember the
very early versions of lharc which took EXTREMELY long times to compress.
maybe 3-5 times longer than arc or zoo. this lharc is among the best, if
not the best version of lharc, but it is far from being the best archiver
overall, In My Humble Opinion....

comments??? rebuffs??? name calling???

-bill
[e-mail]


--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: [e-mail]

------------------------------

Date: 26 Sep 91 05:06:48 GMT
From: noao!asuvax!cs.utexas.edu!usc!apple!netcomsv![e-mail] (Matthew
 Seitz)
Subject: ST Magazines (was More Lies From Atari?)
To: [e-mail]

In article <[e-mail]> [e-mail] (Steve Yelvington)
 writes:
>
>There's nothing wrong with the DTP software used to produce these
>magazines. The limiting factors are:
>
>   -- The output devices. Typesetting a magazine on a 300dpi laser
>      printer isn't going to yield professional-quality output
>      regardless of the software used to place the text on the page.
>      Some ST magazines (and ``fanzines'' is probably a good description)
>      can't afford any better, sad to say.

Can't even afford to take the Postscript files down to the local printshop
for 600 dpi or 1200 dpi output before photocopying?  I can't believe the
Atari magazines are hurting that badly.
--
                                        Matthew Seitz
                                        [e-mail]

------------------------------

Date: 26 Sep 91 05:04:35 GMT
From: noao!asuvax!cs.utexas.edu!usc!apple!netcomsv![e-mail] (Matthew
 Seitz)
Subject: ST Magazines (was Re: More Lies From Atari?)
To: [e-mail]

In article <[e-mail]> [e-mail] (Richard Covert) writes:
>
>The rags you mentioned are the standard examples give by all
>Atari Apologists (AA) (TM by Covert)!! And while they are all
>good mags, they are NOT glossy nationally distributed mags which
>show up in the big bookstores. they are rags which you have to
>hunt to find. SO, novice Atarians wouldn't even know about them.
>

1)  If they are "good mags", why do you call them "rags"?  To me, "rag" implies
a poor magazine.

2)  Personally, I'll take "good mags" over "glossy, nationally distributed mags"
any day of the week.  As you point out later, many times the "glossy, nationally
distributed mags" are often little more than cheerleaders.

3)  Well, if you were able to hunt enough to buy an Atari ST, I'd think finding
the magazines would be easy.  Look on the shelves of the store where you bought
the computer.

Honestly, while I understand the desire for more widespread support for the ST,
I don't see it as a requirement.  The ST works and works well, even if its not
advertised.  There continues to be new, good software written for it, even if
 its
not by big name companies.  And there continue to be good magazines, even if
they aren't full color glossies, and you can't find them at Walden Books.


Yes, the ST is a hobby computer, with a small cult following by DOS standards.
But that's a far cry from saying the ST is dead or dying.  How many people out
there have ever heard of UseNet?  How many slick magazines cover RN?  But no one
suggests UseNet is dying.  In fact, I'd say its booming.

I think there's still room for the ST to continue to live alongside the big
two (DOS and Mac) and alongside it's cousin the Amiga.  You may have to look
a little harder to find support, but it's there.
--
                                        Matthew Seitz
                                        [e-mail]

------------------------------

Date: 22 Sep 91 06:34:46 GMT
From: mcsun!unido!mcshh!malihh!pfunk![e-mail] (Michael
 Kistenmacher)
Subject: TeX, which do I get? (Now that I kno
To: [e-mail]

In <[e-mail]>, [e-mail] writes:

>Hu? As far as I know, Lutz Birkhahn has just finished the new version (and
>the newest version of Metafont is 2.7x, isn't it?)
>
Yes, you're right. Sorry, but I got confused of the version-numbers. 2.9
was the release-number of the old Metafont 1.7. I don't know the new
version from Luth Birkhahn, so forgive me that I didn't mention.

Bye....Michael

--
/------------------------------------\
| Michael Kistenmacher /  blackbox   |
| 2000 Hamburg 61  / Schippelsweg 64 |
| West Germany / ++ 49 40 552 37 66  |
\------------------------------------/

------------------------------

Date: 27 Sep 91 13:22 UT
From: /PN=COLIN.W.HUNT/O=SPRINTINTL/ADMD=TMAILUK/C=GB/@sprint.com
Subject: Trip-A-Tron (Colourspace)
To: [e-mail]

Sometime ago someone posted a message asking for a copy of Trip-A-Tron,
the Light Synth for the ST by Jeff Minter.  Well, I can't offer my copy
of Trip-A-Tron but thought that everyone may be interested in the news
that Jeff has made the ST version of Colourspace shareware, and it therefore
should soon be available on PD libraries everywhere.

There are also rumours that Trip-A-Tron _may_ be made PD, but I don't believe
this (but you never know!)

Colin

------------------------------

End of Info-Atari16 Digest
******************************